Embodiments of the present invention relate generally to the field of system or data security and more particularly to providing dynamic and/or conditional extensions to a security policy.
Security policies for accessing computer systems or resources can be “hard-coded” into applications that control access to those systems or resources. For example, an application controlling access to a file or group of files can include code for authenticating and/or authorizing a user requesting to access the file or files. While effective, such an approach presents problems in that it is rather inflexible. That is, since the security policy is hard-coded into the application, changing the policy generally requires recoding and recompiling the source code of the application. For large systems, this can be time consuming and inefficient. Furthermore, code revisions present the possibility of new problems or bugs being introduced into the system requiring time and effort to troubleshoot. Worse yet is the possibility that such problems may go undetected creating new vulnerabilities for the system.
Attempts to address some of these problems have been made using externally defined security policies that can be changed without modifying the application code. One example of an approach that provides an externally defined security policy is the Java Authentication and Authorization Service (JAAS). As is known in the art, JAAS provides methods for controlling login, authentication, authorization and other access control functions. JAAS methods can use external configuration files, databases, directories, etc. in which a security policy can be defined. Applications using JAAS to control access to resources can pass the path of the configuration file defining the security to the JAAS runtime during startup. In this way, the applications do not need to include code defining the security policy. Rather, the policy is defined externally in the configuration file and can be changed by modifying the configuration file without modifying the code of the application.
However, such an approach still has drawbacks. Primarily, the external configuration files that define the security policy and the JAAS methods that use the configuration files to control access to resources do not allow for conditional definition of permissions in the security policy. That is, the statements in the configuration file grant particular users or groups of users permission to access particular resources or groups of resources. However, these statements do not allow for granting of such permission only if a specified condition is met. For example, a security policy may be desired in which managers are allowed to modify records of only those employees who report to that manager, i.e., permission is granted to the manager to modify a record only if the employee represented by that record reports to that manager. Such a dynamic security policy, which can and often does change at runtime during policy evaluation, would be difficult to capture in the statically-configured JAAS policy. To do so, the configuration file would need to list specifically those files or groups of files to which the manager could be granted access. Such a definition would require significant administrative overhead to manage and maintain as work assignments and employees change.
Hence, there is a need in the art for externally defined security policies that allow for conditional and/or dynamic definitions in the policy.